home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Night Owl 6
/
Night Owl's Shareware - PDSI-006 - Night Owl Corp (1990).iso
/
033a
/
prevnt31.zip
/
WHAT'S.NEW
< prev
Wrap
Text File
|
1990-10-13
|
9KB
|
200 lines
PREvent 3.10
PCBoard Rotary Event Manager
Release 10-13-90
by Jeff Woods
Users new to the 3.x series, please skip to the 3.0 notes, as the bug
fixes herein do not concern you unless you are naturally curious.
_________________________________________________________________________
Welcome back to a release-a-day, but this SHOULD be the last bug fix to
the month specific events. While installing this on the Telix BBS I
discovered what I thought was a minor bug. In all my home
run-throughs, testing every possible setup I could think of, everything
worked, so I sat down to write the docs. As I was writing, it occured
to me that DA/31 should cause it to run on the last day of the month, no
matter HOW many days the month had in it. So I went back and added
that one line, carefully thinking out the logic in that section. The
testing sequence I used was about an hour long, and my logic couldn't be
that far off (so I thought) so it was not retested. BAD mistake,
folks. That threw one DILLY of a bug in the program, for which I
apologize. When looking at the printout at work, it seemed that the
bug would ONLY affect those who had a DA/01 to be run earlier in the
file than the current event. So I let it ride until I got home. Now
4 hours later, I finally have what turned into a monster of a problem
licked, and yes, completely run through the testing series again, and
not one jot has changed in this posting. That little line change
(added an extra 'or' to and 'if' statement) caused it to ALWAYS use the
last event found that was valid, to in effect not stop looking after the
first valid event found.
In the process, I also straightened up the error-trapping on the time of
the events, locking out 23:58 to 00:02 as PCBoard does.
I also discovered an EXTREMELY obscure bug, so thorough was the testing
this time. It seems that PREvent would, when happening on a D02/29 in
a non-leap year, tell you you had an invalid day of the month on that
line. Now if it is February, it will accept a 29 for the day of the
month, and simply skip it if it is not a leap year. Why ANYONE would
want to run the events ONLY on a leap year is beyond me, but now that
definitely works.
I honestly think I got the thing working right this time, but then, I
said that last time, didn't I? <grin> Well, what do you expect for
free? <another grin> Let's hope this time is the charm, and we don't
need a third time.
PREvent 3.0
PCBoard Rotary Event Manager
Release 10-12-90
by Jeff Woods
_________________________________________________________________________
Re-wrote completely, streamlining a few routines, and modularizing the
code a bit. I know you don't care about that *too* much, but I was
busting my hump to get the last version working correctly, and it wasn't
too pretty at all. Now it's much more readable, although still pretty
much uncommented.... ;-)
Fixed a few minor bugs in error trapping invalid entries in the data
file. Added error trapping to the field for the TIME of an event.
Fixed a moderate bug in computing events that were the first to occur on
a Sunday (i.e. first one in PREVENT.LST with a 6 in the data line).
This only hit you if this was the ONLY event to run on Sunday, and the
last event was the ONLY one to run on Saturday.
Added support for day of the MONTH specific events. Below is the
excerpt from the new docs about how this works.
-----------------------------------------------------------------------
The new optional format for the first line for an event is new to
version 3.0. It allows events to run only on specific days of the
MONTH, or in a given month only. Substituting this line for a valid
days of the month line will allow this, if the following format for
month-specific events is followed:
Dmm/dd
Where mm is the month, and dd is the day. Both MM and DD MUST have two
digits, so use D01/01 for January first, etc. You may substitute the
letter "A" for mm, and it will run on the dd'th day of EVERY month. An
example line for that might be for events that compress and clean up
caller logs on the first of each month:
DA/01
The slash is significant, and must separate mm and dd.
Here are a few examples of events that will run on given days of the
MONTH:
D05/15 (will run ONLY on may 15th)
DA/10 (will run on the tenth of EVERY month)
DA/31 (will run on the LAST day of every month with 31 days)
D02/29 (will run once every four years, on leap year)
Yes, Prevent is smart enough to make a few assumptions now. It knows
how many days are in each month and adjusts for leap years as well. It
also will adjust automatically to operate flawlessly, determining which
event is next (there was a minor bug in the day of the week specific
routines in 2.5 - fixed).
-----------------------------------------------------------------------
Unlike the 2.x series, in which I joined Omen in the release of the day
club, I took my time here, carefully testing out each possible
configuration, even the obscure ones. I am fairly confident that since
this one was not rushed out the door that it is sans pests.
------------------------------------------------------------------------
Lastly, some hints on what to do with this new-found power.
Set up an event to run:
DA/01
00:03,n,4,y,30
Have it compress your caller logs (these go down by roughly 85%) and
then delete the buggers. If you are using Sam Smith's CAL14S20 or
some other such, the event can also reset the .SAV files to keep a
bulletin of JUST the month's activity, all hands off.
Set up spaced events. Let's say you want to reset Tradewars every
three months. Four events spaced out such will relieve you of having to
do that.
Set up an event every six months to run Norton Calibrate or Gibson's
Spinrite at the deepest scan. It may take a while, but you'll never
have to wonder if it's time to do it again. It is always a GOOD idea
to do a low level once every six months unless you are using SCSI or
ESDI formats.
Set up an event once a month (if you have a tape backup) to do a FULL
backup of the system while you sleep. Then have bi-weekly events do
incrementals on your most important files, like USERS, etc. It
relieves you of having to back up.
Message packing is nice, and so is disk optimizing, but it can be hard
on your disk. If you have the space, set up a full Norton's Speed Disk
or some such once a month, or maybe twice. You can do events TWICE a
month simply by having:
DA/01 and
DA/15
Then you can use a de-fragger that is much easier on the drive every
other day (via a 0246 event) such as Fasttrax or Vopt. Prevent will
thus help you prolong the life of your hard disk.
------------------------------------------------------------------------
Well, enough rambling. I thought I'd give you some insight as to why I
added the new monthlies, and as to how I now have my system configured
with the new features. I'm sure you'll think of others.
And yes, PREvent 3.0 is STILL public domain software. I retain the
copyright to the work in that only I can say I wrote it, distribute
source code (no, I won't), or sell it (no, I don't - it's FREE). But
anyone is welcome to use it, abuse it, give it to others, or simply
throw it away. I wrote it because I needed it, and it'd be pretty
blasted selfish not to let you use it as well. If you DO like the
program and feel you simply MUST do something for me, tell your users
about my board and it's largest and most well kept catalog of Adlib and
Sound Blaster Files in North America. We are the only board that rates
our Blaster files, and listens to (and cleans up pops and breaks from
poor recordings) each and every file we obtain. So, enjoy, and let me
know how you like the new found freedom.
Jeff Woods The Musical Chair
October 12th, 1990 HST Dual Standard
Toronto, ON Adlib/SoundBlaster Files
1:17 am EST 416-438-3009
-------------------------------------------------------------------------
Prevent 2.5 released 09/09/90
Thanks to Dave Pointer of Grayson, GA, for pointing out (no pun intended) a
logic error in the way error levels were returned in 2.0 through 2.3.
Prevent has always returned the errorlevel based on the NEXT event to
run, but with the addition of day specific events, the errorlevel may no
longer be valid if an event is skipped because it is not a specific day.
Thus, the errorlevel now returned is based on the CURRENT event running,
and will require some changes to your EVENT.SYS. I reccommend reading
the PREVENT.DOC file that deals with the section on using the
errorlevels as it makes things all clear.
The docs were completely re-written as with this change, new users would
have to read the old docs backwards, and it could get very confusing.